-------------------------------------- Chapitre IV - dotNET ---------------------------------------
Conclusion
Je conclurai simplement car l'essentiel a été dit...
Ce qu'il faudra retenir c'est qu'on peut attaquer l'analyse d'un programme en .NET de différentes manières et qu'il est intéressant de comprendre le lien entre les deux approches présentées ici. Un programme en DotNet n'est pas un binaire traditionnel comme ceux réalisés en ASM. Disons qu'ils ont comme seul point commun leur structure, au même titre qu'un programme DOS, afin que Windows sache quoi en faire. Pour ce qui est de l'écriture même du programme, on est en face d'un langage intermédiaire (MSIL = MicroSoft Intermediate Language) incompréhensible par le processeur et c'est la raison pour laquelle OllyDbg v1.10 ne peut pas en faire une analyse statique, mais il doit s'attacher au processus déjà lancé.
L'interrogation de PaPa Bango va trouver réponse ici : Le framework .NET est une machine virtuelle, comme celle de WinDev ou d'autres, et c'est lui qui
se charge de la conversion "à la volée" du code MSIL en assembleur afin que l'application soit "compatible Windows".
A partir de là, Olly peut déboguer l'application, mais vous aurez compris que toute modification est temporaire !
Toutefois OllyDbg v2 est capable au même titre que Reflector de nous présenter ce code IL... mais il est un peu moins pratique et le débogage se fera toujours sous la forme ASM et non MSIL !
Pour finir, je dirais qu'en terme de protection logicielle, le principal point faible du DotNet est l'extrême simplicité à le reverser... d'où l'intérêt d'utiliser des techniques d'obfuscations sur le code source. Cependant sur cette cible, on peut voir que cette technique n'est pas maitrisée par son auteur ou que ses connaissances en reverse engineering sont insuffisantes !